Rating e-commerce transactions

ABSTRACT

Methods of the present invention allow for rating eCommerce transactions. An exemplary method for rating an eCommerce transaction may comprise the steps of identifying a plurality of data indicating the trustworthiness of a Hosting Provider, a Merchant, and/or a Customer, collecting the data, and generating a Transaction Trust Rating for an eCommerce transaction, with the Transaction Trust Rating being based upon the collected data. The Transaction Trust Rating may be stored in a Repository accessible to Internet users. A Transaction Trust Rating Indicator (indicative of the Transaction Trust Rating) also may be provided to the Hosting Provider, Merchant, and/or Customer and may take the form of a certificate for display on a webpage, a change in color of an address bar on a browser, and/or an alphanumeric ranking.

CROSS REFERENCE TO RELATED PATENT APPLICATIONS

This patent application is a continuation of U.S. patent applicationSer. No. 13/569,387 to Neil Warner, with filing date Aug. 8, 2012 andentitled “RATING E-COMMERCE TRANSACTIONS,” which is a continuation ofU.S. patent application Ser. No. 12/033,662 to Neil Warner, with filingdate Feb. 19, 2008 and entitled “VALIDATING E-COMMERCE TRANSACTIONS,” acontinuation of U.S. patent application Ser. No. 12/033,629 to NeilWarner, with filing date Feb. 19, 2008 and entitled “RATING E-COMMERCETRANSACTIONS,” and a division of U.S. patent application Ser. No.12/619,048 to Neil Warner, with filing date Nov. 16, 2009 and entitled“VALIDATING E-COMMERCE TRANSACTIONS,” which is a continuation of U.S.patent application Ser. No. 12/033,662 to Neil Warner, with filing dateFeb. 19, 2008 and entitled “VALIDATING E-COMMERCE TRANSACTIONS,”priority from which is hereby claimed.

FIELD OF THE INVENTION

The present inventions generally relate to the field of businesstransactions conducted over the Internet and, more specifically, methodsfor rating and validating eCommerce transactions.

BACKGROUND OF THE INVENTION

A network is a collection of links and nodes (e.g., multiple computersand/or other devices connected together) arranged so that informationmay be passed from one part of the network to another over multiplelinks and through various nodes. Examples of networks include theInternet, the public switched telephone network, the global Telexnetwork, computer networks (e.g., an intranet, an extranet, a local-areanetwork, or a wide-area network), wired networks, and wireless networks.

The Internet is a worldwide network of computers and computer networksarranged to allow the easy and robust exchange of information betweencomputer users. Hundreds of millions of people around the world haveaccess to computers connected to the Internet via Internet ServiceProviders (ISPs). Content providers place multimedia information (e.g.,text, graphics, audio, video, animation, and other forms of data) atspecific locations on the Internet referred to as webpages. Websitescomprise a collection of connected, or otherwise related, webpages. Thecombination of all the websites and their corresponding webpages on theInternet is generally known as the World Wide Web (WWW) or simply theWeb.

Prevalent on the Web are multimedia websites, some run by Merchants,offering and selling goods and services to individuals and organizations(i.e., potential Customers). Websites may consist of a single webpage,but typically consist of multiple interconnected and related webpages.Websites, unless extremely large and complex or have unusual trafficdemands, typically reside on a single server and are prepared andmaintained by a single individual or entity. Menus and links may be usedto move between different webpages within the website or to move to adifferent website as is known in the art. The interconnectivity ofwebpages enabled by the Internet can make it difficult for Internetusers to tell where one website ends and another begins.

Websites may be created using HyperText Markup Language (HTML) togenerate a standard set of tags that define how the webpages for thewebsite are to be displayed. Users of the Internet may access contentproviders' websites using software known as an Internet browser, such asMICROSOFT INTERNET EXPLORER or MOZILLA FIREFOX. After the browser haslocated the desired webpage, it requests and receives information fromthe webpage, typically in the form of an HTML document, and thendisplays the webpage content for the user. The user then may view otherwebpages at the same website or move to an entirely different websiteusing the browser.

Browsers are able to locate specific websites because each website,resource, and computer on the Internet has a unique Internet Protocol(IP) address. Presently, there are two standards for IP addresses. Theolder IP address standard, often called IP Version 4 (IPv4), is a 32-bitbinary number, which is typically shown in dotted decimal notation,where four 8-bit bytes are separated by a dot from each other (e.g.,64.202.167.32). The notation is used to improve human readability. Thenewer IP address standard, often called IP Version 6 (IPv6) or NextGeneration Internet Protocol (IPng), is a 128-bit binary number. Thestandard human readable notation for IPv6 addresses presents the addressas eight 16-bit hexadecimal words, each separated by a colon (e.g.,2EDC:BA98:0332:0000:CF8A:000C:2154:7313).

IP addresses, however, even in human readable notation, are difficultfor people to remember and use. A Uniform Resource Locator (URL) is mucheasier to remember and may be used to point to any computer, directory,or file on the Internet. A browser is able to access a website on theInternet through the use of a URL. The URL may include a HypertextTransfer Protocol (HTTP) request combined with the website's Internetaddress, also known as the website's domain name. An example of a URLwith a HTTP request and domain name is: http://www.companyname.com. Inthis example, the “http” identifies the URL as a HTTP request and the“companyname.com” is the domain name.

Domain names are much easier to remember and use than theircorresponding IP addresses. The Internet Corporation for Assigned Namesand Numbers (ICANN) approves some Generic Top-Level Domains (gTLD) anddelegates the responsibility to a particular organization (a “registry”)for maintaining an authoritative source for the registered domain nameswithin a TLD and their corresponding IP addresses. For certain TLDs(e.g., .biz, .info, .name, and .org) the registry is also theauthoritative source for contact information related to the domain nameand is referred to as a “thick” registry. For other TLDs (e.g., .com and.net) only the domain name, registrar identification, and name serverinformation is stored within the registry, and a registrar is theauthoritative source for the contact information related to the domainname. Such registries are referred to as “thin” registries. Most gTLDsare organized through a central domain name Shared Registration System(SRS) based on their TLD.

Some Internet users, typically those that are larger and moresophisticated, may provide their own hardware, software, and connectionsto the Internet. But many Internet users either do not have theresources available or do not want to create and maintain theinfrastructure necessary to host their own websites. To assist suchindividuals (or entities), hosting companies exist that offer websitehosting services. These Hosting Providers typically provide thehardware, software, and electronic communication means necessary toconnect multiple websites to the Internet. A single Hosting Provider mayliterally host thousands of websites on one or more hosting servers.

Websites allow individuals and businesses to share their information andconduct business with a large number of Internet users. Many productsand services are offered for sale on the Internet, thus elevating theInternet to an essential tool of commerce. Merchants, whether largecorporations, small corporations, or individuals, are rapidly creatingwebsites to take advantage of the growing number of Customers using theInternet and customers' increasing willingness to purchase goods andservices over the Web. Websites created by Internet businesses may bereached by millions of Internet savvy customers, thereby allowingInternet businesses to offer their products and services to a very largepool of potential Customers.

For Internet users and businesses alike, the Internet continues to beincreasingly valuable. More people use the Web for everyday tasks, fromsocial networking, shopping, banking, and paying bills to consumingmedia and entertainment. eCommerce (i.e., buying and selling products orservices over electronic systems such as the Internet) is growing, withbusinesses delivering more services and content across the Internet,communicating and collaborating online, and inventing new ways toconnect with each other.

At least three distinct entities are involved in any eCommercetransaction conducted via a website: a Merchant; a Customer; and theHosting Provider hosting the Merchant's website. During the eCommercetransaction, each of these entities has access to information about theother entities that may allow for fraud. For example, a fraudulentMerchant and/or Hosting Provider may engage in phishing (i.e.,fraudulently acquiring sensitive information, such as usernames,passwords and credit card details, by masquerading as a trustworthyentity in an electronic communication), and a fraudulent Customer mayattempt to use an unauthorized credit card. It is therefore importantthat each entity involved in an eCommerce transaction be trusted by theother entities.

Applicant, however, has noticed that presently-existing methods do notprovide adequate means for entities involved in eCommerce transactionsto determine whether sufficient trust levels exists to proceed with atransaction. For the foregoing reasons, there is a need for the methodsof rating and validating eCommerce transactions and relatedfunctionality as described herein.

SUMMARY OF THE INVENTION

The limitations cited above and others are substantially overcomethrough the methods disclosed herein, which allow for rating andvalidating eCommerce transactions.

An exemplary method for rating an eCommerce transaction may comprise thesteps of identifying a plurality of data indicating the trustworthinessof a Hosting Provider, Merchant, and/or Customer, collecting the data,and generating a Transaction Trust Rating for an eCommerce transaction,with the Transaction Trust Rating being based upon the collected data.The Transaction Trust Rating may be stored in a Repository accessible toInternet users. A Transaction Trust Rating Indicator (indicative of theTransaction Trust Rating) may be provided to the Hosting Provider,Merchant, and/or Customer and may take the form of a certificate fordisplay on a webpage, a change in color of an address bar on a browser,and/or an alphanumeric ranking.

An exemplary method for validating an eCommerce transaction may comprisethe steps of validating a Hosting Provider, validating a Merchant usingthe Hosting Provider to host an eCommerce website, validating a Customerwho may purchase goods or services from the Merchant via the eCommercewebsite, and (if the Hosting Provider, Merchant, and Customer arevalidated) approving an eCommerce transaction involving the HostingProvider, Merchant, and/or Customer.

The above features and advantages of the present invention will bebetter understood from the following detailed description taken inconjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flow diagram illustrating a possible embodiment of a methodfor rating eCommerce Transactions.

FIG. 2 is a flow diagram illustrating a possible embodiment of a methodfor rating eCommerce Transactions.

FIG. 3 is a flow diagram illustrating a possible embodiment of a methodfor rating eCommerce Transactions.

FIG. 4 is a flow diagram illustrating a possible embodiment of a methodfor rating and validating eCommerce Transactions.

FIG. 5 is a flow diagram illustrating a possible embodiment of a methodfor rating and validating eCommerce Transactions.

FIG. 6 is a flow diagram illustrating a possible embodiment of a methodfor validating eCommerce Transactions.

FIG. 7 is a flow diagram illustrating a possible embodiment of a methodfor validating eCommerce Transactions.

DETAILED DESCRIPTION

The present inventions will now be discussed in detail with regard tothe attached drawing figures which were briefly described above. In thefollowing description, numerous specific details are set forthillustrating the Applicant's best mode for practicing the invention andenabling one of ordinary skill in the art to make and use the invention.It will be obvious, however, to one skilled in the art that the presentinvention may be practiced without many of these specific details. Inother instances, well-known machines, structures, and method steps havenot been described in particular detail in order to avoid unnecessarilyobscuring the present invention. Unless otherwise indicated, like partsand method steps are referred to with like reference numerals.

Rating eCommerce Transactions

An exemplary method for rating an eCommerce transaction is illustratedin FIG. 1. In this example embodiment, a Transaction Trust Rating for aneCommerce transaction is generated (Step 100). The Transaction TrustRating is an indicator of the overall trustworthiness of a potentiale-Commerce transaction, which may comprise any transaction involving thesale or purchase of goods or services over the Internet. At least threedistinct entities may be involved in any such eCommerce transaction: aMerchant; a Customer; and the Hosting Provider hosting the Merchant'swebsite.

A Merchant may be any individual, entity, business, organization, and/orgovernmental entity selling goods or services, perhaps via an eCommercewebsite accessible to potential Customers over the Internet. A HostingProvider may host the Merchant's eCommerce website, perhaps on a server.As non-limiting examples, the server could be an application,communication, mail, database, proxy, fax, file, media, web,peer-to-peer, or standalone server and may use any server format knownin the art or developed in the future (possibly a shared hosting server,a virtual dedicated hosting server, a dedicated hosting server, or anycombination thereof). The Hosting Provider may comprise any individual,entity, automated system, domain name registrar, domain name registry,reseller of a domain name registrar, Internet service provider, websiteoperator, and/or any combination thereof. A Customer may be anyindividual, entity, business, organization, and/or governmental entitywho may purchase goods or services, perhaps via a Merchant's eCommercewebsite. The embodiments described herein place no limitation upon thegoods or services that may form the basis of an eCommerce transaction.

The Transaction Trust Rating may be based upon a plurality of dataindicating the trustworthiness of the Hosting Provider, Merchant, and/orCustomer. Data indicative of trustworthiness may include, but is notlimited to, data indicative of whether a Hosting Provider satisfies thePayment Card Industry Data Security Standard. The Payment Card IndustryData Security Standard (PCI DSS) was developed by the major credit cardcompanies as a guideline to help organizations that process cardpayments to prevent credit card fraud, hacking, and/or other securitythreats. A company processing, storing, or transmitting payment carddata must be PCI DSS compliant or risk losing their ability to processcredit card payments and being audited and/or fined. Merchants mustvalidate their compliance periodically. Alternatively, the data may beindicative of the Hosting Provider's computer system's security, such aswhether they have been infiltrated and used by known spammers and/orphishers.

The reputation of a Merchant's domain name and/or website also may berelevant trustworthiness data. Whether a Merchant's website is SecureSockets Layer (SSL)-certified, for example, may indicate whether theMerchant has been verified as the authorized controller of the website'sdomain name, is currently registered with a government authority, and/orlegally exists as an incorporated corporation. SSL certificates areusually displayed on a Merchant's website and typically indicate thatthe Merchant's website utilizes at least some level of securecommunications protocol. Relevant trustworthiness data also may comprisea Customer's purchase history, whether a Customer is authorized to use acredit card, and/or a Customer's eCommerce reputation. Any additionaldata known in the art or identified in the future that is indicative ofthe trustworthiness of a Hosting Provider, Merchant, and/or Customeralso may be used.

Any method of generating a Transaction Trust Rating based on theabove-described plurality of data may be used. As a non-limitingexample, the illustrated method may utilize mathematical algorithms thatgenerate a Transaction Trust Rating based on an average (weighted ornon-weighted) of numerical trustworthiness values assigned to each ofthe plurality of data. Data possessing stronger indicia oftrustworthiness may be given more weight than others. Alternatively, theTransaction Trust Rating may comprise the sum of the values assigned tothe individual data points. Such mathematical algorithms may be executedby a computer processor following software-embodied instructions.Importantly, a Transaction Trust Rating may be generated even when dataindicating the trustworthiness of all three entities is unavailable. Iftrustworthiness data is unavailable for any entity, the generation step(Step 100) may proceed with only the available data.

A more detailed method for rating eCommerce transactions is illustratedin FIG. 2. In addition to the steps illustrated in FIG. 1, this exampleembodiment may include the steps of identifying (Step 200) andcollecting (Step 210) the plurality of data indicating thetrustworthiness of the Hosting Provider, Merchant, and/or Customer. Suchdata may be identified and collected by analyzing, as non-limitingexamples, the steps taken by the Hosting Provider to become an eCommerceprovider (e.g., meeting the Payment Card Industry Data SecurityStandard, becoming a domain name registry or registrar, becomingauthorized to sell SSL-certificates), steps taken by the Merchant toestablish his business (e.g., registering a domain name or developing awebsite), and/or a Customer's eCommerce history.

Internal information about the Hosting Provider, such as IP addressused, results of internal and external scans, security teamavailability, and system log data, are all types of information that maybe collected. As a non-limiting example, data points provided byorganizations such as SHADOW SERVER and/or TEAM CYMRU may be used toidentify infected systems within the Hosting Provider. If the Merchanthas registered a domain name, a domain name validation analysis (such asGODADDY.COM's CERTIFIED DOMAIN) may be completed to identify theindividual or entity that registered the domain name and determine theirreputation. The domain name registrant also may be validated via creditcard fraud detection. Whether the Merchant's eCommerce website isSSL-certified is yet another data point that may be collected. Withregard to Customer data, his purchase history (from the subject Merchantand others) may be identified and collected. Credit card fraud detectionmay be used to determine whether the Customer is authorized to use acredit card. The IP addresses of the Customer's personal computers alsomay be obtained and compared with known comprised personal computers toestablish a data point to warn the Merchant of possible maliciousactivity.

A more detailed method for rating eCommerce transactions is illustratedin FIG. 3. In addition to the steps illustrated in FIG. 2, this exampleembodiment may include the steps of storing the Transaction Trust Rating(indicating the Transaction Trust Rating) and/or the plurality oftrustworthiness data in a Repository (Step 300) and providing aTransaction Trust Rating Indicator to the Hosting Provider, Merchant,and/or Customer (Step 310). The Repository may comprise, as non-limitingexamples, a magnetic storage device, disk drive, FLASH or RAM memory,local database, online database, desktop database, server-side database,relational database, hierarchical database, network database, objectdatabase, object-relational database, associative database,concept-oriented database, entity-attribute-value database,multi-dimensional database, semi-structured database, star schemadatabase, XML database, file, collection of files, spreadsheet, and/orother means of data storage located on a server, a computer, a client,or any other storage device. As a specific example, the Repository maycomprise a Trust Rating Database that is accessible to any Internet Uservia the Internet.

Merchants, Customers, Hosting Providers, and/or any other Internet usermay access the database, review the Transaction Trust Rating and/or theplurality of trustworthiness data, and decide whether sufficient trustexists to proceed with the transaction. Alternatively, a TransactionTrust Rating Indicator (indicating the Transaction Trust Rating) may beprovided to the Hosting Provider, Merchant, and/or Customer (Step 310).As non-limiting examples, the Transaction Trust Rating Indicator maycomprise a marker for display on a website that may represent theTransaction Trust Rating as an alpha-numeric score, a grade (e.g., A-F),a color on a spectrum (e.g., green to red, with green representingtrustworthiness and red representing lack of trustworthiness), a numberof stars, a certificate for display on a webpage, and/or a change incolor of an address bar on a browser. Any other means of indicating alevel of trustworthiness that is known in the art or developed in thefuture also may be used as a Transaction Trust Rating Indicator.

The Transaction Trust Rating Indicator may be provided to the recipientvia any means of transferring data known in the art or developed in thefuture. Such methods can generally be classified in two categories: (1)“pull-based” data transfers where the receiver initiates a datatransmission request; and (2) “push-based” data transfers where thesender initiates a data transmission request. Both types are expresslyincluded in the embodiments illustrated herein, which also may includetransparent data transfers over network file systems, explicit filetransfers from dedicated file-transfer services like FTP or HTTP,distributed file transfers over peer-to-peer networks, file transfersover instant messaging systems, file transfers between computers andperipheral devices, and/or file transfers over direct modem or serial(null modem) links, such as XMODEM, YMODEM and ZMODEM. Data streamingtechnology also may be used to effectuate data transfer. A data streammay be, for example, a sequence of digitally encoded coherent signals(packets of data) used to transmit or receive information that is intransmission. Any data transfer protocol known in the art or developedin the future may be used including, but not limited to: (1) those usedwith TCP/IP (e.g., FTAM, FTP, HTTP, RCP, SFTP, SCP, or FASTCopy); (2)those used with UDP (e.g., TFTP, FSP, UFTP, or MFTP); (3) those usedwith direct modem connections; (4) HTTP streaming; (5) Tubular DataStream Protocol (TDSP); (6) Stream Control Transmission Protocol (SCTP);and/or (7) Real Time Streaming Protocol (RTSP).

In the embodiment illustrated in FIG. 4, an eCommerce transaction isapproved (Step 400) if the Transaction Trust Rating generated in Step100 exceeds a pre-determined value. This step may, as a non-limitingexample, be performed by a Merchant's website. Accordingly, the Merchant(or a Hosting Provider on behalf of the Merchant) may determine aminimum Transaction Trust Rating that must be met before an eCommercetransaction is processed. Conversely, automated purchasing software(perhaps with a corporate purchasing department) may decline to purchasegoods or services from a Merchant should the Transaction Trust Ratingfail to exceed a pre-determined value. Step 400 also may be performedmanually, e.g., a Customer declining a purchase based on the TransactionTrust Rating.

In the embodiment illustrated in FIG. 5, a plurality of data indicatingthe trustworthiness of a Hosting Provider, a Merchant, and/or a Customeris identified (Step 200) and collected (Step 210), a Transaction TrustRating for an eCommerce transaction is generated (Step 100), saidTransaction Trust Rating and/or said plurality of data is stored (Step300), perhaps in a Trust Rating Database accessible to a plurality ofInternet Users via the Internet, a Transaction Trust Rating Indicator isprovided (Step 310) to said Hosting Provider, said Merchant, and/or saidCustomer, and an eCommerce transaction is approved (Step 400) if saidTransaction Trust Rating exceeds a pre-determined value.

Validating eCommerce Transactions

Several different methods may be used to validate eCommercetransactions. The streamlined example embodiment illustrated in FIG. 6comprises the steps of validating a Hosting Provider (Step 600),validating a Merchant who may be using the Hosting Provider to host aneCommerce website (Step 610), validating a Customer who may purchasegoods or services from the Merchant via the eCommerce website (Step620), and (if the Hosting Provider, Merchant, and Customer arevalidated) approving an eCommerce transaction involving the HostingProvider, Merchant, and/or Customer (Step 400).

As Illustrated in FIG. 7, the Hosting Provider may be validated (Step600) by any method of establishing the Hosting Provider'strustworthiness including, but not limited to, determining that theHosting Provider satisfies a pre-established criteria (Step 700), suchas the PCI DSS discussed in detail above. Additionally or alternatively,the security of the Hosting Provider's systems may be validated (Step705), perhaps by determining whether they have been infiltrated and usedby known spammers and/or phishers. Internal information about theHosting Provider, such as IP address used, results of internal andexternal scans, security team availability, and system log data, are alltypes of information that may be collected. External data pointsprovided by organizations such as SHADOW SERVER and TEAM CYMRU also maybe used to identify infected systems within the Hosting Provider.

The Merchant may be validated (Step 610) by any method of establishingthe Merchant's trustworthiness including, but not limited to determiningthat said Merchant satisfies a pre-established criteria (Step 710). Byway of example, the pre-established criteria may comprise the Merchant'sregistration and/or rating with the Better Business Bureau,incorporation as a governmentally-recognized corporation, and/orregistration and/or rating with an online rating service (e.g., EBAY,AMAZON, and/or GOOGLE seller ratings). Additionally or alternatively,the reputation of a domain name registered to the Merchant may beverified (Step 715). If the Merchant has registered a domain name, adomain name validation analysis (such as GODADDY.COM's CERTIFIED DOMAINprocess) may be completed to identify the individual or entity thatregistered the domain name and determine their reputation. The domainname registrant also may be validated via credit card fraud detection.The reputation of a website operated by the Merchant (Step 720) also maybe evaluated in a similar manner. Determining whether a website operatedby the Merchant is SSL-certified (Step 725) is yet another, easy toaccomplish, method of validating a Merchant. SSL certificates areusually displayed on a Merchant's website and typically indicate thatthe Merchant's website utilizes at least some level of securecommunications protocol.

The Customer may be validated (Step 620) by any method of establishingthe Customer's trustworthiness including, but not limited to,determining that the Customer satisfies a pre-established criteria (Step730), perhaps a minimum credit score. Alternatively, the Customer'spurchase history and/or eCommerce reputation may be analyzed (Steps 735and 745), possibly by reviewing their registration and/or rating with anonline rating service (e.g., EBAY, AMAZON, and/or GOOGLE purchaserratings). Confirming that the Customer is authorized to use a creditcard (Step 740) is another available method of validating the Customer.

Other embodiments and uses of the above inventions will be apparent tothose having ordinary skill in the art upon consideration of thespecification and practice of the invention disclosed herein. Thespecification and examples given should be considered exemplary only,and it is contemplated that the appended claims will cover any othersuch embodiments or modifications as fall within the true scope of theinvention.

All of the methods disclosed herein may be performed manually, partiallyautomated, or fully automated. The methods also may be embodied incomputer-readable media with instructions executable by a processor,which when executed by the processor, causes said processor to performthe steps of each method.

The Abstract accompanying this specification is provided to enable theUnited States Patent and Trademark Office and the public generally todetermine quickly from a cursory inspection the nature and gist of thetechnical disclosure and in no way intended for defining, determining,or limiting the present invention or any of its embodiments.

The invention claimed is:
 1. A method, comprising: receiving, by atleast one server computer, a request to execute an eCommercetransaction; identifying, by the at least one server computer, amerchant for the eCommerce transaction, a hosting provider hosting awebsite of the merchant, and a customer of the eCommerce transaction;identifying a first metric indicating a trustworthiness of the merchant;identifying a second metric indicating a trustworthiness of the hostingprovider; identifying a third metric indicating a trustworthiness of thecustomer; calculating a fourth metric indicating a trustworthiness ofthe eCommerce transaction using the first metric, the second metric, andthe third metric; when the fourth metric exceeds a predeterminedthreshold, executing the eCommerce transaction; and when the fourthmetric does not exceed the predetermined threshold, rejecting theeCommerce transaction.
 2. The method of claim 1, wherein the firstmetric indicates a reputation of a domain name registered to themerchant.
 3. The method of claim 1, wherein the first metric indicatesthe website of the merchant is or is not secure socket layer (SSL)certified.
 4. The method of claim 1, wherein the second metric indicatesthat the hosting provider satisfies or does not satisfy a Payment CardIndustry Data Security Standard.
 5. The method of claim 1, wherein thesecond metric identifies a security history of a system operated by thehosting provider.
 6. The method of claim 1, wherein the third metricidentifies a purchase history of the customer.
 7. The method of claim 1,wherein the third metric indicates that the customer is or is notauthorized to use a credit card.
 8. The method of claim 1, including,after calculating the fourth metric, transmitting an indication of thefourth metric to at least one of the merchant and the customer.
 9. Themethod of claim 8, wherein the indication of the fourth metric is agraphic configured for display on a web page.
 10. The method of claim 8,wherein the indication of the fourth metric is at least one of acertificate for display on a webpage, a change in color of an addressbar on a browser, and/or an alphanumeric ranking.
 11. The method ofclaim 1, including, when calculating the fourth metric, applying aweighting to at least one of the first metric, the second metric, andthe third metric.
 12. The method of claim 1, wherein calculating thefourth metric includes summing numerical values of the first metric, thesecond metric, and the third metric.
 13. A method, comprising:identifying a first metric indicating a trustworthiness of a merchant ofa transaction; identifying a second metric indicating a trustworthinessof a hosting provider of the transaction; identifying a third metricindicating a trustworthiness of customer of the transaction; calculatinga fourth metric indicating a trustworthiness of the transaction using atleast two of the first metric, the second metric, and the third metric;and when the fourth metric exceeds a predetermined threshold, executingthe transaction.
 14. The method of claim 13 including, after calculatingthe fourth metric, transmitting an indication of the fourth metric to atleast one of the merchant and the customer.
 15. The method of claim 14,wherein the indication of the fourth metric is a graphic configured fordisplay on a web page.
 16. The method of claim 14, wherein theindication of the fourth metric is at least one of a certificate fordisplay on a webpage, a change in color of an address bar on a browser,and/or an alphanumeric ranking.
 17. The method of claim 13, including,when calculating the fourth metric, applying a weighting to at least oneof the first metric, the second metric, and the third metric.
 18. Themethod of claim 13, wherein calculating the fourth metric includessumming numerical values of the first metric, the second metric, and thethird metric.
 19. A system, comprising: at least one server computer incommunication with a network, the at least one server computer includinga processor configured to: identify a first metric indicating atrustworthiness of a merchant of a transaction; identify a second metricindicating a trustworthiness of a hosting provider of the transaction;identify a third metric indicating a trustworthiness of customer of thetransaction; calculate a fourth metric indicating a trustworthiness ofthe transaction using at least two of the first metric, the secondmetric, and the third metric; and when the fourth metric exceeds apredetermined threshold, execute the transaction.
 20. The system ofclaim 19, wherein the processor is configured to, after calculating thefourth metric, transmit an indication of the fourth metric to at leastone of the merchant and the customer.